REMARKS 



Claims 1-32 remain pending in the application. Reconsideration is respectfully 
requested in light of the following remarks. 

Provisional Double Patenting Rejection : 

The Examiner provisionally rejected claims 1-32 under the judiciary created 

doctrine of nonstatutory double patenting in view of claims 1-38 of co-pending 

Application No. 10/090,893. The provisional nonstatutory double patenting rejection is 

based on In re Schneller, 397 F.2d 350, 158 USPQ 210 (CCPA 1968), as covered in 

MPEP 804.II.B.2. Applicants reference the third paragraph of MPEP 804.II.B.2: 

The decision in In re Schneller did not establish a rule of general 
application and thus is limited to the particular set of facts set forth in 
that decision. The court in Schneller cautioned "against the tendency to 
freeze into rules of general application what, at best, are statements 
applicable to particular fact situations." Schneller, 397 F.2d at 355, 158 
USPQ at 215. Nonstatutory double patenting rejections based on Schneller 
will be rare . The Technology Center (TC) Director must approve any 
nonstatutory double patenting rejections based on Schneller. If an 
examiner determines that a double patenting rejection based on Schneller 
is appropriate in his or her application, the examiner should first consult 
with his or her supervisory patent examiner (SPE). If the SPE agrees 
with the examiner then approval of the TC Director must be obtained 
before such a nonstatutory double patenting rejection can be made, 
(emphasis added) 

First, Applicants note that the MPEP clearly emphasizes again that nonstatutory 
double patenting rejections based on Schneller will be rare and are limited to the 
particular set of facts set forth in that decision. The Examiner has not shown how the 
particular facts of Schneller apply to the present application. Applicants further note that 
the supervisory patent examiner (SPE) must agree with a double patenting rejection based 
on Schneller, and the Technology Center (TC) Director must approve any nonstatutory 
double patenting rejections based on Schneller. The MPEP Examiner Note 1 for form 
paragraph f 8.39 states that: 

This form paragraph should only be used where approval from the TC 
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Director to make a nonstatutory double patenting rejection based on In re 
Schneller has been obtained. 

Since approval of both the SPE and TC Director are required before a nonstatutory 
double patenting rejection based on Schneller can be made, Applicants respectfully 
request formal indication that both the SPE and the TC Director have approved of 
the nonstatutory double patenting rejection based on Schneller. 

Prior Art Rejections : 

The Examiner rejected claims 1-32 under 35 U.S.C. § 102(e) as anticipated by or, 
in the alternative, under 35 U.S.C. § 103(a) as obvious over Mansour et al. (U.S. 
Publication 2002/0129096) (hereinafter "Mansour"). Applicants respectfully traverse 
these rejections for at least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest a server ... configured to generate a small device document in a small device 
format from a document in a server format . The Examiner cites paragraphs [0022] - 
[0024] and paragraph [0055] as disclosing this limitation. However, these paragraphs do 
not describe a server generating such a document. Instead, they describe a method for 
displaying application data on a client device: "the distributed architecture transmits only 
data and a brief description of how to display it... between the server and client. The 
client side software, using the native GUI controls, produces the UI elements on the 
client...". Nothing in this citation discloses that the server generates a document in a 
small device format from a document in a server format , as recited in claim 1 . In fact, 
these paragraphs include a description that application data and UI (user interface) 
information are separated in Mansour' s architecture, and that the server provides a UI 
form definition to the client device, which renders the UI according to the form. Since 
the application data and its display format information are separated on the server and 
only combined for display on the client device, Mansour actually teaches away from a 
server generating a document in a small device format , as recited in claim 1 . 
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Further regarding claim 1, contrary to the Examiner's assertion, Mansour fails to 
teach or suggest that, to generate a small device document in a small device format from 
a document in a server format, the server is further configured to exclude one or more 
formats for content of the document in the server format from the small device document. 
The Examiner cites paragraph [0118] "server versions" as disclosing this limitation. This 
paragraph states that, "the client application 728 is preferably designed to be compatible 
with any number of UI server versions." Paragraph [0118] also states, "the client 
application 728 (along with the communication interface element 730 and the OS- 
dependent code 732) is embedded in read-only memory in the client device." Thus, this 
passage describes how a static client application interacts with different UI modules. 
Clearly this has absolutely nothing to do with documents in small device formats, 
much less with generating a small device document in a small device format * or with 
excluding one or more formats for content of the document in the server format from 
the small device document * as recited in claim 1. 

Mansour also fails to teach or suggest that the server is further configured to 
provide the small device document to a small device coupled to the server, contrary to the 
Examiner's assertion. The Examiner cites paragraph [0053] "suitably configured" as 
disclosing this limitation. However, this citation states only, "System 100 is suitably 
configured to deliver information, data, control commands, and the like, from at least one 
server device (or system) to any number of remote end user client devices." It does not 
describe that any of these items is a small device document in a small device format, nor 
that any of these items is generated by the server in the manner recited in claim 1. In 
addition, Mansour teaches away from this limitation in paragraph [0073] which 
describes, "opening large messages or attachments is much simpler because the 
attachment is actually being opened on the UI server , and only a single page view (and 
possibly some additional cached data) need be transmitted to the client at any one time", 
and in paragraph [0076], which states, "With the distributed UI system, the client device 
only displays and stores a relatively small amount of data , and more data is downloaded 
from the UI server as the user scrolls down to view it." Thus, Mansour clearly does not 
teach or suggest providing the small device document to a small device, as recited in 
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claim 1. 

Further regarding claim 1, Mansour fails to teach or suggest the small device... is 
configured to modify the small device document to produce a modified version of the 
small device document. The Examiner's citation (paragraph [0185] "updated version") 
refers to "a process for handling data modifications, where such modifications originate 
at the data source" in which "the UI server may test whether the modified data is 
associated with a data item that is already cached at the client (query task 1708). For 
example, the modified data may be an updated version of a cached data item. In this 
regard, the UI server may poll its shadow cache to determine the current status of the 
client cache. If the modified data item is not cached at the client, then data modification 
process 1700 exits (this modified data item will be maintained by the UI server until the 
client device calls the respective application or until the data item is modified again)." 
This paragraph describes that once an "updated version" of a cached application data 
item is produced by an external source, the server decides whether to "push" the data 
item to the client or to wait until later to transmit the modified data item. This has 
absolutely nothing to do with a small device being configured to modify the small 
device document (which was generated by the server) to produce a modified version 
of the document, as recited in claim 1. 

Finally, Mansour fails to teach or suggest the server is further configured to 
generate a modified version of the document in the server format from the modified 
version of the small device document, wherein, to generate a modified version of the 
document in the server format from the modified version of the small device document, 
the server is further configured to restore the one or more formats for content of the 
document in the server format excluded from the small device document. The Examiner 
cites paragraph [0185] "updated version", paragraph [0217] "the UI server are configured 
to process and manipulate to perform different UI form for the client device" and 
paragraphs [0053-0218] "suitably configured" and "restore or render format" as 
disclosing these limitations. However, the "updated version" of paragraph [0185] refers 
to an application data item that may be "pushed" to a client. Paragraph [0217] describes 
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UI server 2404 performing UI formatting 2416 to format and configure different UI form 
definitions 2418 for use by the client device 2402. These UI form definitions 2418 are 
not modified or unmodified documents in a server or small device format. Instead, 
they are definitions of display formats themselves. See, e.g., paragraph [0068] in which 
UI forms are defined: 

As used herein, a "UI form" is a description of the layout of the 
client device display at any given moment. A UI form definition specifies 
a list of controls, the respective locations of the controls as rendered on the 
client device display screen, event scripts, data sources, and possibly other 
characteristics. A UI form preferably does not include the user's data that 
is to be displayed by the UI controls, but it may specify where a given 
control can retrieve source data items (e.g., a pointer to a memory location 
at the client device), and/or which event scripts are executed in response to 
the activation of certain controls. 

The Examiner's reference to "restore or render format" is found nowhere in 
Mansour. In fact, the word "restore" is not found in Mansour at all. In addition, all 
references to "rendering" refer to a client device rendering a UI form and/or 
rendering a user interface according to a UI form. 

Thus, the Examiner's citations clearly have nothing to do with a modified version 
of a document in either a small device format or a server format , much less with the 
server generating a modified version of a document in server format from a modified 
version of a small device document in small device format. There is nothing in 
Mansour to teach or suggest restoring one or more formats for content as recited in 
claim 1. 

The Examiner submits that it was clear "that the UI server could manipulate the 
configured process by a suitable configured or restored the format in the server format 
excluded from the client document. Doing so would provide the flexibility to combine 
and merge the documents between the server- client formats by using any network 
device." The Examiner's assertions are completely unsupported by the actual teachings 
of the reference. First, as discussed above, there is nothing in Mansour to teach or 
suggest the server generating a small device document in small device format and 



10/091,203 (5681-10700/P7346) 



6 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P C. 



excluding one or more formats for content. Therefore, there would be no need to restore 
any such excluded formats. Second, the system of Mansour, in which application data 
and display formats are maintained separately by the server and only application data and 
some information about how to display it (e.g., UI forms or commands) are transmitted 
between server and client, teaches away from the Examiner's suggestion to "combine 
and merge the documents between the server- client formats". Finally, there is nothing in 
the cited art that provides a motivation to change this principle of the operation in order 
to "provide flexibility", as the Examiner suggests. As stated in the MPEP §2143.01 "If 
the proposed modification or combination of the prior art would change the principle of 
operation of the prior art invention being modified, then the teachings of the references 
are not sufficient to render the claims prima facie obvious . In re Ratti , 270 F.2d 810, 123 
USPQ 349 (CCPA 1959). . ." {emphasis added). 

In the Response to Arguments section of the Office action mailed June 21, 2006, 
the Examiner submits that Mansour taught, (in paragraph [0161]) "the server sends form 
to client device (i.e., PDA) in a suitable format" and that this teaches "generate a format 
for the small device document." However, claim 1 does not recite generating a "format 
for the small device document" but instead recites that the server is configured to 
generate a small device document in a small device format from a document in a server 
format. The Examiner appears to be referring to the following description in paragraph 
[0161]: 

"In response to this request, the UI server retrieves (or generates) the UI 
form definition and sends it back to the client device in a suitable format 
(task 1214)." 

This passage does not describe generating a small device document, but a UI form 
definition (e.g., a set of display format rules) that is then used by the client device to 
generate a form (e.g., a template) in which to display content (Mansour, [0162].) The UI 
form definition itself is not a small device document generated by the server from a 
document in a server format. Instead it is a definition of a UI form . Even if the UI form 
could be considered to be a document, it is not the form that is sent to the client device 
from the server, but its definition. In addition, there is nothing in Mansour that teaches or 
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suggests that a UI form or the form definition described are generated bv the server from 

a document in a server format , as required by claim 1 . In fact, there is no description at 

all about how these UI form definitions are created. Paragraph [0068], quoted above, 

describes the difference between a "UI form" and a "UI form definition". Paragraph 

[0217] includes only this brief description of the server configuring UI form definitions: 

The UI server 2404 obtains the device capabilities 2414 for the client 
device 2402, preferably from the client device 2402 itself, from a third 
party entity or process, or internally in the form of a preloaded database. 
The device capabilities 2414 represent characteristics or parameters of the 
client device 2402 that can impact, restrict, or otherwise have a bearing on 
the format or configuration of the user interface 2412. The UI server 2404 
performs UI formatting 2416 to format and configure different UI form 
definitions 2418 for use bv the client device 2402 . The specific form 
definitions 2418 are based upon or otherwise determined by the client 
device capabilities 2414 and any number of server-based applications 
2420 accessible to the client device 2402 (the server-based applications 
2420 are configured to process and manipulate source data items 2422 for 
presentment to the end user via user interface 2412). 

There is nothing in this passage, or elsewhere in Mansour, that teaches or suggests 
that formatting and configuring different UI form definitions (which are clearly not small 
device documents ) has anything to do with excluding one or more formats for content of 
a document in a server format , as required by claim 1 . Therefore, Mansour clearly fails 
to teach or suggest wherein the server is configured to generate a small device document 
in a small device format from a document in a server format, wherein, to generate a 
small device document in a small device format from a document in a server format, the 
server is further configured to exclude one or more formats for content of the document 
in the server format from the small device document: and wherein the server is further 
configured to provide the small device document to a small device coupled to the server \ 
as recited in claim 1 . 

Applicants also remind the Examiner that to establish a prima facie obviousness 
of a claimed invention, all claim limitations must be taught or suggested by the prior art. 
In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 2143.03. As 
discussed in detail above, Mansour fails to teach or suggest many of the limitations of 
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Applicants' claim 1. 

For at least the reasons above, the rejection of claim 1 is not supported by the 
cited art and removal thereof is respectfully requested. Similar remarks apply also to 
independent claims 10, 19 and 27, which recite limitations similar to those in claim 1. 

Regarding claim 2, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest in paragraph [0118] the document in the server format is an office productivity 
document. As discussed above, this paragraph refers to client application 728 and has 
nothing to do with documents in server formats, much less office productivity documents. 
Furthermore, there is nothing in Mansour to teach or suggest a server generating an office 
productivity document in a small device format from an office productivity document in 
a server format, as recited in Applicants' claims. 

For at least the reasons above, the rejection of claim 2 is not supported by the 
cited art and removal thereof is respectfully requested. 

Regarding claim 3, Mansour fails to teach or suggest wherein, to restore the one 
or more formats for content of the document in the server format excluded from the small 
device document, the server is further configured to compare modified content of the 
modified version of the small device document to corresponding content of the document 
in the server format to determine one or more formats for the modified content of the 
modified version of the small device document to be merged with the document in the 
server format. The Examiner cites paragraphs [0185] ("modified version") and [0074] 
("a comparison") as teaching these limitations. As noted above regarding claim 1, 
paragraph [0185] refers to an application data item that may be "pushed" to a client. 
There has nothing to do with restoring formats that were excluded from a small device 
document. Paragraph [0074] states, "Thus, the event scripts can expedite online 
operation while enabling some offline functionality, above example illustrates some of 
the advantages of the distributed UI system, particularly in comparison to conventional 
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terminal server architectures ," This clearly has nothing to do with the limitations of any 
of Applicants claims. 

Mansour also fails to teach or suggest the server is configured to merge the 

modified content of the modified version of the small device document into the document 

in the server format in accordance with the determined one or more formats for the 

modified content. In the Response to Arguments section of the Office Action mailed 

June 21, 2006, the Examiner submits that Mansour taught "merging the content" by 

disclosing "merge the data" in paragraph [0075]. This passage is as follows: 

Notably, the data can be reduced to its purest component, only the 
essential parts of the data need to be sent, the UI is appropriate for the 
client device platform, and clients need not be specially configured to 
support each application. For example, in a typical fat client environment, 
opening an email with an attached word processor document requires a 
client side email application that communicates with an email server, 
along with a client side application that can open and display the word 
processor document. However, by using the distributed UI system, data is 
converted on the UI server for rendering by the client device in its native 
UI (unlike a terminal server, which uses the server's UI). The client device 
will then merge the data with the UI components to provide an interactive 
interface with a persistent state. Consequently, additional functionality can 
be added to the UI server (e.g., the ability to open a different file type) 
without having to install additional software on the client device. 

This passage clearly describes the server converting data for rendering on the 
client device by reducing it to its purest component and only sending the essential parts 
of the data to the client. This data is then merged with UI components (i.e., a suitable UI 
form) to provide the interface on the client . This clearly has nothing to do with a 
modified version of the small device document (modified on the client device) being 
merged into a document in the server format on the server . 

Finally, as discussed above regarding claim 1, Mansour fails to teach or suggest 
generating a small device document and excluding one or more formats for content. 
Therefore, Mansour would have no reason to restore such formats at all, much less in the 
specific manner recited in claim 3, and does not teach or suggest such restoration. 
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For at least the reasons above, the rejection of claim 3 is not supported by the 
I cited art and removal thereof is respectfully requested. 

Regarding claim 4, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest wherein, to generate a modified version of the document in the server format 
from the modified version of the small device document, the server is further configured 
to determine differences between the modified version of the small device document and 
the document in the server format, wherein each determined difference indicates changed 
content of the modified version of the small device document; and for each of the 
determined differences, merge corresponding changed content of the modified version of 
the small device document with the document in the server format. The Examiner cites 
paragraph [0118] "server versions" as disclosing these limitations. However, as 
discussed above, paragraph [0118] refers to a static client application 728 and has nothing 
to do with generating modified documents in server formats or small device formats, 
much less with generating one from the other, determining differences between them, or 
merging corresponding changed content, according to the limitations recited in claim 4. 

In addition, as discussed above regarding claim 3, Mansour fails to teach or 
suggest merge corresponding changed content of the modified version of the small device 
document with the document in the server format in paragraph [0075] or elsewhere. 

For at least the reasons above, the rejection of claim 4 is unsupported by the cited 
art and removal thereof is respectfully requested. 

Regarding claim 5, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest generate a modified version of the small device document in the server format 
from the modified version of the small device document in the small device format; and 
compare the modified version of the small device document in the server format to the 
document in the server format. The Examiner cites paragraph [0185] "updated version" 
as disclosing these limitations. However, as discussed above, the "updated version" of 
paragraph [0185] refers to an application data item that may be "pushed" to a client. It 
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has nothing to do with a modified version of a document in either a small device format 
or a server format , much less with generating a modified version of a document in server 
format from a modified version of a small device document in small device format or 
with comparing the modified version of the small device document in the server format to 
the (original) document in the server format, as recited in claim 5. 

For at least the reasons above, the rejection of claim 5 is unsupported by the cited 
art and removal thereof is respectfully requested. 

Regarding claim 6, Mansour fails to teach or suggest generate a modified 
document in an interim format from the modified version of the small device document 
and generate a document in the interim format from the document in the server format, in 
paragraph [0118] "server versions". As discussed above, paragraph [0118] refers to a 
static client application 728 and has nothing to do with generating modified documents in 
server formats or small device formats, much less with generating a document in an 
interim format from a document in a server format, as recited in claim 6. There is no 
such interim format disclosed in paragraph [0118] or elsewhere in Mansour. 

Further regarding claim 6, Mansour fails to teach or suggest determine one or 
more differences between the modified document in the interim format and the document 
in the interim format. The Examiner cites paragraph [0217] "different form" as 
disclosing this limitation. However, as discussed above, the "different form" of 
paragraph [0217] refers different UI form definitions 2418 for use by the client device 
2402. These UI form definitions 2418 are not modified and unmodified documents in an 
interim format. Instead, they are definitions of display formats themselves. Furthermore, 
this citation has nothing to do with determining differences between multiple form 
definitions, much less with determining differences between multiple documents in the 
same interim format , as recited in claim 6. 

Finally, Mansour fails to teach or suggest for each of the determined differences, 
[the server is configured to] merge corresponding changed content of the modified 
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document in the interim format with the document in the interim format; and generate the 
modified version of the document in the server format from the document in the interim 
format. Here, the Examiner cites paragraph [0075] "converted and merged" as disclosing 
these limitations. However, this citation describes that application data is converted on 
the UI server for rendering by the client device in its native UI (unlike a terminal server, 
which uses the server's UI) and then the client device merges the data with the UI 
components to provide an interactive interface. This passage illustrates the fact that 
rather than generating documents with different formats, the server of Mansour maintains 
application data and display formats separately and relies on client devices to merge data 
and formats. Clearly, the Examiner's citation has nothing to do with the server merging 
changed content of a modified document in the interim format with the (original) 
document in the interim format or with generating a modified version of the document in 
the server format from the document in the interim format, as recited in claim 6. 

For at least the reasons above, the rejection of claim 6 is not supported by the 
cited art and removal thereof is respectfully requested. 

Regarding claim 7, contrary to the Examiner's assertion, Mansour fails to teach or 
suggest the server is further configured to resolve differences between the modified 
version of the document in the server format and another modified version of the 
document in the server format to generate a synchronized version of the document in the 
server format . The Examiner again cites paragraph [0185] "updated version" as 
disclosing this limitation. However, as discussed above, the "updated version" of 
paragraph [0185] refers to an application data item that may be "pushed" to a client. 
There is nothing in this citation to describe that such a "push" is used to resolve 
differences between two modified versions of a document in server format in order to 
synchronize them. In fact, paragraph [0185] specifically refers to the server "pushing" 
application data items to update these data items at the client , not to generate a 
synchronized document in the server format (which would be maintained on the server .) 
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For at least the reasons above, the rejection of claim 7 is not supported by the 
cited art and removal thereof is respectfully requested. 

Regarding claim 8, Mansour fails to teach or suggest display the differences 
between the modified version of the document and the other modified version of the 
document. The Examiner cites paragraph [0074] "display in comparison" as disclosing 
this limitation. However, the only reference to a display in this paragraph is as follow, "if 
the user chooses the "Compose New Message" from an Inbox view, the event script 
associated with that button will be executed by the client device and a "New Message" 
form may be displayed." This clearly has nothing to do with displaying the differences 
between two different modified versions of a document , as recited in claim 8. 

Furthermore, Mansour fails to teach or suggest for each difference, accept user 
input specifying which version is to be used in the synchronized version of the document. 
Here, the Examiner again cites paragraph [0185] "updated version" as disclosing this 
limitation. As discussed at length above, this paragraph describes a server pushing a 
changed application data item to a client. It has nothing to do with synchronizing two 
modified versions of a document . Furthermore, there is nothing in this citation that 
describes accepting user input specifying which version of each difference between two 
modified documents is to be used in the synchronized version of the document, as recited 
in claim 8. 

For at least the reasons above, the rejection of claim 8 is not supported by the 
cited art and removal thereof is respectfully requested. 

Regarding claim 9, Mansour fails to teach or suggest wherein the server 
comprises a set of policies configured for use in resolving differences between versions of 
documents in the server format, wherein, to resolve differences between the modified 
version of the document in the server format and another modified version of the 
document in the server format, the server is further configured to, for each difference: 
determine one of the polices corresponding to the difference; and apply the determined 
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policy to the difference to determine which version is to be used in the synchronized 
version of the document. First, the Examiner fails to address the limitation wherein the 
server comprises a set of policies configured for use in resolving differences between 
versions of documents in the server format Applicants assert that since Mansour fails to 
disclose resolving differences between multiple, modified versions of documents in a 
server format, it also clearly fails to disclose a set of policies to be applied to such 
resolving. 

The Examiner cites paragraph [0185] "updated version" as disclosing, "determine 
one of the policies (i.e., version) corresponding to the difference; and apply the 
determined policy to the difference to determine which version is to be used in the 
synchronized version of the document." As previously noted, Mansour fails to disclose 
resolving differences between two modified versions of a document in the server format 
at all Applicants also assert that "versions" of application data items, as described in 
paragraph [0185], are clearly not analogous to " policies configured for use in resolving 
differences between versions of documents" as recited in claim 9. Furthermore, there is 
nothing in this citation or elsewhere in Mansour that discloses the server is further 
configured to, for each difference: determine one of the polices corresponding to the 
difference; and apply the determined policy to the difference to determine which version 
is to be used in the synchronized version of the document. 

For at least the reasons above, the rejection of claim 9 is not supported by the 
cited art and removal thereof is respectfully requested. 

Claims 10-32 include limitations similar to those discussed above regarding 
claims 1-9 and were rejected for the same reasons as claims 1-9. Applicants assert that 
the arguments presented above apply with equal force to claims 10-32, as well. 
Therefore, for at least the reasons presented above, the rejection of claims 10-32 is not 
supported by the cited art and removal thereof is respectfully requested. 
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The Examiner further rejected claims 1-32 under 35 U.S.C. § 103(a) as being 
unpatentable over Ketonen et al. (U.S. Patent 7,035,828) (hereinafter "Ketonen") in view 
of Mousseau et al. (U.S. Patent 6,477,529) (hereinafter "Mousseau"). Applicants 
respectfully traverse this rejection for at least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, Ketonen in view of 
Mousseau fails to teach or suggest the server is configured to generate a small device 
document in a small device format from a document in a server format, wherein, to 
generate a small device document in a small device format from a document in a server 
format, the server is further configured to exclude one or more formats for content of the 
document in the server format from the small device document. The Examiner cites 
Ketonen (column 21, lines 5-40) as teaching this limitation. However, this paragraph 
states, in part: 

"The mini-server 220 interprets the request and invokes the rule for 
retrieving Amazon order status information using the login name and 
password data from the URL. The mini-server 220 obtains the HTML 
reply page from Amazon and extracts the desired status information . The 
mini-server 220 then generates a response HTML document which 
provides the status information in a format which can be displayed on a 
Palm device." 

Thus, Ketonen does not teach generating a small device document in the 
manner recited in claim 1 (excluding one or more formats for content of the 
document in the server format from the small device document), but instead 
describes extracting information from one type of document (an Amazon reply 
page) and generating a different type of document (a response document) in a 
format that can be displayed on a Palm device. 

Ketonen in view of Mousseau also fails to teach or suggest wherein the small 
device is configured to modify the small device document to produce a modified version 
of the small device document; and provide the modified version of the small device 
document to the server. The Examiner cites Ketonen (column 11, lines 30-50, "local 
assistant Client-side customization application, the modified status".) However, this 
passage describes making local customizations to an application , and storing these 
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customizations (or preferences) stored locally (on local interaction database 106). 

There is nothing in this passage that teaches or suggest that these customizations are 
modifications of a small device document , nor that they are provided to the server , as 
recited in claim 1. 

In addition, Ketonen in view of Mousseau also fails to teach or suggest wherein 
the server is further configured to generate a modified version of the document in the 
server format from the modified version of the small device document. The Examiner 
again cites Ketonen, column 21, lines 5-40, "the mini-server generates a response HTML 
document or modified document which provides the status information in a format which 
can be displayed on a Palm device." As noted above, this passage describes the mini- 
server generating a document in the client format . It teaches or suggests nothing about 
generating a modified version of the document in the server format from the modified 
version of the client document , as required by claim 1. 

The Examiner admits that Ketonen does not explicitly detail the server is further 
configured to restore the one or more formats for content of the document in the server 
format excluded from the small device document, and relies on Mousseau to teach this 
limitation. The Examiner submits, "In the same endeavor, Mousseau discloses an 
apparatus and method for dynamically linking information sent to a viewing device 
including an information translator on gateway/server exchanging data to the client 
handheld device" (column 3, line 55 - column 4, line 8.) However, this passage in 
Mousseau refers to preparing information for transmission to a handheld device : "To 
assist the information translator 16 in its task of getting information and preparing it for 
transmission to the handheld device 22 , a content filter and storage area 18 is provided, 
which is coupled to the information translator 16." This passage, whether considered 
alone or in combination with Ketonen, clearly has nothing to do with a server 
restorine one or more formats for content of a document in the server format that 
were excluded from a small device document 

The Examiner submits that it would have been obvious to one of ordinary skill in 
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the art at the time the invention was made "to in corporate the merging new content data, 
commands as taught by Mousseau into the Ketonen' s apparatus in order to utilize the 
Client-Side Customization application. Doing so would provide a dynamic control over 
what information is transmitted to the wireless device [Mousseau, column 2, lines 20- 
22]." Applicants note, however, that the Examiner has not cited anything in his 
remarks regarding combining the references to show that Mousseau teaches 
"merging new content data, commands" nor anything in either reference to teach or 
suggest that such a feature would improve the Client-Side Customization 
application of Ketonen in the way suggested by the Examiner. 

In addition, adding the features of Mousseau to the Client-Side Customization 
application of Ketonen would not result in the present invention. Instead, such a 
combination may include many features related to preparation of information and 
transmission of the information to a handheld device , but would teach or suggest nothing 
about the specific limitations of Applicants' claimed invention discussed above. 

Applicants also remind the Examiner that to establish a prima facie obviousness 
of a claimed invention, all claim limitations must be taught or suggested by the prior art. 
In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 2143.03. As 
discussed in detail above, Ketonen and Mousseau, taken alone or in combination, fail to 
teach or suggest all the limitations of Applicants' claim 1. 

For at least the reasons above, the rejection of claim 1 is unsupported by the cited 
art and removal thereof is respectfully requested. Similar remarks apply also to 
independent claims 10, 19 and 27, which recite limitations similar to those in claim 1. 

Regarding claim 3, contrary to the Examiner's assertion, Ketonen in view of 
Mousseau clearly fails to teach or suggest wherein, to restore the one or more formats for 
content of the document in the server format excluded from the small device document, 
the server is further configured to: compare modified content of the modified version of 
the small device document to corresponding content of the document in the server format 
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to determine one or more formats for the modified content of the modified version of the 
small device document to be merged with the document in the server format; and merge 
the modified content of the modified version of the small device document into the 
document in the server format in accordance with the determined one or more formats 
for the modified content. First, as discussed regarding claim 1, Ketonen in view of 
Mousseau does not teach or suggest restoring one or more formats for content . 
Therefore, they cannot (and do not) teach or suggest restoring formats for content 
according to the specific limitations recited in claim 3. 

For example, the Examiner cites Ketonen, column 17, lines 34-48 ("the broker 
searches for matching information".) This passage describes the broker searching for 
information in response to a query from a mobile client. This has absolutely nothing to 
do with comparing modified content of a small device document with corresponding 
content of the document in the server format The Examiner's citation in Mousseau 
(column 10, lines 1-20 and column 9, lines 1-15, "merging the new content") describes a 
Gateway device receiving a set of restrictions from a handheld device and restricting the 
flow of information from a server to the handheld device by removing portions of a 
document according to the restrictions. This clearly does not teach that the server 
modifies the document in server format to merge changes made to a document in a client 
format. Instead, the Gateway receives the document from the server and removes part of 
it. This passage also clearly does not teach anything about determining one or more 
formats for the modified content of the modified version of the small device document to 
be merged with the document in the server format, as recited in claim 3. In addition, in 
Mousseau, the Gateway device translates information from the server into a format 
compatible with wireless delivery. The server does not generate small device documents 
in a small device format at all, as required by many of Applicants' claims (column 6, 
lines 5-15.) 

For at least the reasons above, the rejection of claim 3 is unsupported by the cited 
art and removal thereof is respectfully requested. Similar remarks as discussed above in 
regard to claim 3 apply also to dependent claims 12, 20 and 28. 
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Regarding claim 4, contrary to the Examiner's assertion, Ketonen in view of 
Mousseau clearly fails to teach or suggest wherein, to generate a modified version of the 
document in the server format from the modified version of the small device document, 
the server is further configured to determine differences between the modified version of 
the small device document and the document in the server format, wherein each 
determined difference indicates changed content of the modified version of the small 
device document; and for each of the determined differences, merge corresponding 
changed content of the modified version of the small device document with the document 
in the server format. The Examiner again cites Mousseau (column 10, lines 1-20 and 
column 9, lines 1-15, "merging the new content 5 ') as teaching this limitation. However, 
as discussed above regarding claim 3, this passage clearly does not teach or suggest that 
the server is configured to merge corresponding changed content of the modified version 
of the small device documen t with the document in the server format , as required by 
claim 4. Instead, in Mousseau, unwanted content is removed by a Gateway device during 
transmission of a document from the server to the handheld device. In addition, as 
discussed above, in Mousseau, the Gateway device translates information from the server 
into a format compatible with wireless delivery. The server does not generate small 
device documents in a small device format at all, nor does it modify documents in its own 
format according to changes made in a small device document. 

For at least the reasons above, the rejection of claim 4 is unsupported by the cited 
art and removal thereof is respectfully requested. 

Regarding claim 5, contrary to the Examiner's assertion, Ketonen in view of 
Mousseau clearly fails to teach or suggest wherein, to determine differences between the 
modified version of the small device document and the document in the server format, the 
server is further configured to generate a modified version of the small device document 
in the server format from the modified version of the small device document in the small 
device format; and compare the modified version of the small device document in the 
server format to the document in the server format. The Examiner cites Ketonen (column 
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2, lines 42-53, "data matching") as teaching these limitations. This passage includes the 
following reference to "matching": 

The broker searches its database of private requests for requests directed 
to the personal agent, that have no associated reply, and that have 
authentication data matching that provided by the personal agent . . . 

This passage clearly has absolutely nothing to do with Applicants 9 claimed 
invention. In addition, as discussed above, Ketonen in view of Mousseau fails to teach 
determining differences between the modified version of the small device document and 
the document in the server format at all, much less according to the specific limitations 
recited in claim 5. 

For at least the reasons above, the rejection of claim 5 is unsupported by the cited 
art and removal thereof is respectfully requested. 

Regarding claim 6, contrary to the Examiner's assertion, Ketonen in view of 
Mousseau clearly fails to teach or suggest wherein, to generate a modified version of the 
document in the server format from the modified version of the small device document, 
the server is further configured to generate a modified document in an interim format 
from the modified version of the small device document; generate a document in the 
interim format from the document in the server format; determine one or more 
differences between the modified document in the interim format and the document in the 
interim format; for each of the determined differences, merge corresponding changed 
content of the modified document in the interim format with the document in the interim 
format; and generate the modified version of the document in the server format from the 
document in the interim format. The Examiner again cites Mousseau (column 10, lines 1- 
20 and column 9, lines 1-15, "merging the new content") as teaching this limitation. 
However, as discussed above, this passage describes a Gateway device receiving a set of 
restrictions from a handheld device and restricting the flow of information from a server 
to the handheld device by removing portions of a document according to the restrictions. 
This has absolutely nothing to do with generating documents in an interim format in 
order to determine changed content and to merge the changes into a document in the 
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server format. 

For at least the reasons above, the rejection of claim 6 is unsupported by the cited 
art and removal thereof is respectfully requested. 

Claims 12-15, 20-23, and 28-31 include limitations similar to those discussed 
above regarding claims 3-6 and were rejected for the same reasons as claims 3-6. 
Applicants assert that the arguments presented above apply with equal force to these 
claims as well. Therefore, for at least the reasons presented above, the rejection of claims 
12-15, 20-23, and 28-31 is not supported by the cited art and removal thereof is 
respectfully requested. 

Regarding claim 7, contrary to the Examiner's assertion, Ketonen in view of 

Mousseau clearly fails to teach or suggest wherein the server is further configured to 

resolve differences between the modified version of the document in the server format 

and another modified version of the document in the server format to generate a 

synchronized version of the document in the server format. The Examiner cites Ketonen 

(column 1, lines 15-25 "synchronizing") as teaching these limitations. This passage of 

the background section of Ketonen includes the following general statement: 

A PDA typically works together with another computer by sharing and 
"synchronizing' 1 data such as contacts lists and schedule information. 

This generic description of synchronization of data between a PDA and a 
computer neither teaches nor suggests anything about resolving differences between two 
different modified versions of documents in a server format , much less between a 
document in a server format modified according to the modifications of a correspondinR 
document in a small device format and another modified document in the server format, 
as required by claims 1 and 7. 

Similarly, contrary to the Examiner's assertion, this passage neither teaches nor 
suggests the limitations of claims 8 and 9, which recite: wherein, to resolve differences 
between the modified version of the document in the server format and another modified 
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version of the document in the server format, the server is further configured to display 
the differences between the modified version of the document and the other modified 
version of the document; and for each difference, accept user input specifying which 
version is to be used in the synchronized version of the document (claim 8) and wherein 
the server comprises a set of policies configured for use in resolving differences between 
versions of documents in the server format, wherein, to resolve differences between the 
modified version of the document in the server format and another modified version of 
the document in the server format, the server is further configured to, for each difference: 
determine one of the polices corresponding to the difference; and apply the determined 
policy to the difference to determine which version is to be used in the synchronized 
version of the document (claim 9.) There is clearly nothing in this passage that teaches or 
suggests these specific limitations regarding resolving differences between two modified 
documents in the server format . 

For at least the reasons above, the rejection of claims 7-9 is unsupported by the 
cited art and removal thereof is respectfully requested. 

Claims 16-18, 24-26, and 32 include limitations similar to those discussed above 
regarding claims 7-9 and were rejected for the same reasons as claims 7-9. Applicants 
assert that the arguments presented above apply with equal force to these claims as well. 
Therefore, for at least the reasons presented above, the rejection of claims 16-18, 24-26, 
and 32 is not supported by the cited art and removal thereof is respectfully requested. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and prompt notice 
to that effect is respectfully requested. 

If any extension of time (under 37 C.F.R. § 1.136) is necessary to prevent the 
above-referenced application from becoming abandoned, Applicants hereby petition for 
such an extension. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 
501505/5681-10700/RCK. 

Also enclosed herewith are the following items: 
£3 Return Receipt Postcard 
O Petition for Extension of Time 

□ Notice of Change of Address 

□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: September 21. 2006 



Respectfully submitted, 




Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 
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